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Abstract 

This paper describes a collaborative multiagent 
modeling and simulation approach for designing work 
systems. The Brahms environment is used to model 
mission operations for a semi-autonomous robot 
mission to the Moon at the work practice level. It shows 
the impact of human-decision making on the activities 
and energy consumption of a robot. 

A collaborative work systems design methodology is 
described that allows informal models, created with 
users and stakeholders, to be used as input to the 
development of formal computational models. 

1. Introduction 

Work systems involve people, machines, tools, 
documents, and facilities interacting in activities over 
time. These activities produce goods, services or — as is 
the case in the work system described in this paper — 
scientific data. Many work systems we encounter 
everyday have existed over a long period of time, 
improvement of such work systems is often done 
through business process analysis and reengineering [1]. 
But managers must also design work systems de novo. 

One of the challenges of work system design is that 
work systems are often large and complex and persist 
over a long period of time. This makes the design 
process complex and non-deterministic. In this paper we 
describe Brahms, a multiagent modeling and simulation 
(M&S) environment for designing complex interactions 
in human-machine systems. 

In Brahms, we model work processes at the work 
practice level. We describe a case study in which we 
used Brahms to design mission operations for a 
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proposed discovery mission to the Moon — the Victoria 
Mission. We begin by describing our view of work 
practice and how it is modeled in Brahms. We then 
describe Victoria, the model, and simulation results. 

2. Work Practice 

The concept of work practice originates in the 
research disciplines of socio-technical systems, business 
anthropology, and management science. Work systems 
design, as presented here, has its roots in the design ot 
socio-technical systems. This method was developed in 
the 1950s by Eric Trist and Fred Emery [2], to 
understand and leverage the advantages of the social and 
technical aspects of work. Work systems design extends 
this tradition by focusing on both the informal and 
formal fearures of work by applying ethnographic 
panic ipant observation [3]. 

A work practice is defined as the collective activities 
of a group of people who collaborate and communicate, 
while performing these activities synchronously or 
asynchronously. In contrast, a Tayloristic view of work 
abstracts circumstances, tools, and behaviors into an 
idealized transformation of work products by job 
functions. 

To describe how work actually gets done, we need to 
include those aspects of the situation that influence 
individual activity (not only the procedures and 
problem-solving behavior), such as collaboration, 
conversations, “off-task” activities, multi-tasking, 
interruption and resumption of work (and how this is 
managed), informal interaction such as assistance 
outside of job function, use of tools, and facilities [4] 
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Bnhm.% is ,1 MAS environment tor representing work 
practice using a multiagenr rule-based activity language, 
that can be simulated using the Brahms simulation 
engine [51. 

This paper discusses how we have used Brahms to 
design the work system for the proposed Victoria 
mission. The attentive reader might question how we can 
design a work practice ? Indeed, a work practice is not 
designed, but emerges over time However, our interest 
is to determine whether a model at the work practice 
level can be used in the design of a mission. We believe 
that a work practice model is useful, because it provides 
a more detailed and holistic representation of work [6] 

m. 

3. Components of a Brahms Simulation 

Brahms has a multiagent language for describing 
agent and object activities. For a more detailed 
description of the language see [8] [4], A Brahms 
simulation of work practice has seven integrated 
components: 

Agent Model: The group-agent membership 

hierarchy of the people in the work system. Groups may 
be formal roles and' functions or based on location, 
interpersonal relations, interests, etc. 

Object Model: The class-hierarchy of all the domain 
objects and artifacts, e.g., tools, desks, documents, 
vehicles. 

Geography Model: The geographical areas in which 
agents and objects are located, consisting of area- 
definitions (user-defined types of areas, such as 
buildings, rooms, and habitats) and areas (instances of 
area-definitions). 

Activity Model: The behavior of agents and objects 
in terms of the activities they perform over time [9]. 
Agent or object activities are mostly represented at the 
group-level or class-level respectively, but are also often 
specific to agents and objects. Activities arc inherited 
and blended through a priority scheme. 

Timing Model: Constraints on when the activities in 
the activity model, can be performed, represented as 
preconditions of situation-action rules (called 
workframes). Activities take time, as determined by the 
predefined duration of primitive actions. Workframes 
can be interrupted and resumed, making the actual 
length of an activity situation dependent. 

Knowledge Model: An agent's reasoning, 

represented as forward-chaining production rules (called 
( houghtframes ). Thoughtframes can be represented at 
group/class levels and inherited. Thoughtframes take no 
time Inquiry is modeled as a combination of activities 
(eg., detecting information, communicating, and 
rcading/writing documents) and thoughtframes. 

Perception is modeled as conditions attached to 


workframes (called defeefah/es) . thus observation is 
dependent on what the agent is doing 

Communication Model: Acnons by which agents 
and objects exchange beliefs, including telling someone 
something or asking a question A conversation is 
modeled as an activity with communication actions, 
either face-to-face or through some device, »uch as a 
telephone or email. The choice of device and how it is 
used are part of the work practice 

Typically a Brahms model is sketched by specifying 
the geography and groups first. The grain size of the 
simulation clock (time per tick j may vary from 5 
seconds or less to 5 minutes or more, depending on the 
information available and modeling purposes. A model 
might represent a group of people as a single agent, a 
useful heuristic in redesigning a work system. Common 
objects and activities such as telephones and ‘phone 
conversation” may be easily reused and adapted from 
other Brahms models. In general, Brahms models 
represent work with much more detail than business 
process models, but somewhat less detail (and far more 
broadly) than cognitive models (Figure l ). 
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Figure 1. Relation of Brahms models to other models 

Considerable effort is devoted to modeling objects 
(e.g., fax machines) and computer systems, with which 
people interact to accomplish their work. 

4. The Victoria Lunar Mission 

Victoria is the name of a proposed long-term semi- 
autonomous robotic mission to the South Pole region of 
the Moon. The primary mission objective of Victoria is 
to verify the presence of water ice and other volatiles 
within permanently shadowed regions on the Moon. This 
will be accomplished by gathering the necessary lunar 
data for analyzing the history of water and other 
volatiles on the Moon, and by implication in the inner 
solar system. The Victoria team has decided to use a 
high-speed semi-autonomous rover 

One of the biggest constraints in any robotic mission 
is power consumption of the robot. In every activity the 
rover uses energy, therefore the sequence of activities 
for the rover is constrained by the amount of power 
available to complete the sequence. When the robot’s 
batteries are low, it needs to return to a sun-expo>ed spot 
to recharge its batteries. During the Victoria mission the 
rover will traverse into permanentK dark regions on the 
Moon. During these traverses the rover will use its 
neutron detector instrument to detect hydrogen and the 
Sample Acquisition and Transfer Mechanism (SATM) 




Figure 2. Collaborative Modeling Process 


to drill into the lunar surface and take surface samples to 
be investigated using an array of science instruments. 

The work system design problem is to configure the 
mission operations so the robot’s activities inside the 
permanent dark region are most efficient (i.e. consume 
the least amount of energy). 

5. Collaborative Modeling 

To develop a simulation of the Victoria work system, 
we used a collaborative modeling approach with the 
Victoria mission designers. First, we created informal 
static models of the activities of the people, robot, and 
artifacts, the communication and geography, in informal 
design meetings and modeling sessions. Next, we 
translated these descriptions into formal Brahms models, 
producing simulation results (including energy 
measurements described below). The Brahms modeler 
went back to the mission design team and presented the 
result of the simulation. Together they discussed and 
represented more details of the work practice. The 
Brahms modeler implemented the new details into the 
simulation. This Brahms modeling-debug-simulate cycle 
continued until a sufficiently robust and interesting 
design resulted. 

Figure 2 describes our collaborative methodology for 
developing first an informal model and then a formal 
simulation model of the Victoria work practice. 

Method Ml - analyzing work practice: The 
purpose of method Ml is to create an informal static 


description (i.e. a conceptual model) of the work 
practice of a human activity system. For M 1 we use the 
Compendium modeling method [10]. 

Method M2 - formal model of the work practice: 
The purpose of method M2 is to translate the conceptual 
models from Ml into a Brahms model. The Brahms 
modelers and the conceptual modelers do not necessarily 
have to be the same, and in fact, the skill sets for these 
two types of modelers are very different. 

Method M3 - simulation: Using method M3 a 
Brahms simulation of the formal model is developed, by 
running the simulator with the formal model as input. 
M3 is the Brahms compilc-stmulate-debug method. 

Method M4 - observing the simulation: The 
purpose of method M4 is to observe and investigate the 
work practice simulation output, and compare it with the 
actual human activity system. During this cycle the 
actual objective of the work practice simulation project 
is accomplished. Frequently, one modifies the model or 
factual scenarios (e.g., for Victoria, the location of ice in 
the modeled geography) to perform a what-if analysis 

Thus, there is a modeling and simulation cycle 
between Ml, M2, M3 and M4. The methods have to be 
closely integrated for the cycle to be efficient. For 
example, to a certain extern we can automatically 
produce Brahms model components (M2) from informal 
Compendium descriptions (Ml). 
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Figure 3. Victoria wort system 


6. Mission Operations System Design 

The work during in the Victoria mission will be 
distributed over a number of human teams and the 
Victoria rover. By virtue of being people’s arms and 
eyes on the Moon, the teleoperated rover is more of an 
assistant than a simple tool. 

Figure 3 represents the work system elements and 
their relative location during the Victoria mission. The 
Science Team consists of co-located sub-teams: the 
Science Operations Team (SOT), the Instrument 
Synergy Team (1ST), and the Data Analysis and 
Interpretation Team (DAIT). There are two other 
supporting teams: The Data and Downlink Team (DDT) 
and the Vehicle and Spacecraft Operations Team 
(VSOT). The teams communicate with the Victoria 
rover on the lunar surface using the Universal Space 
Network (USN), directly and via a lunar orbiter. The 
flow of data from the rover will be dominated by 
contextual data and science data. This data will come to 
NASA Ames via the Universal Space Network (USN) 
data connection and will be automatically converted in 
near real-time to accessible data formats that can be 
made available to the teams via data access and 
visualization applications. 

Based on previous experience, the mission designers 
hypothesized that many issues will affect the decision 
cycle of the science team, one of which is data overload 


[11]. They therefore specifically addressed the following 
questions in the work system design for Victoria: 

1. How will science data be gathered collaboratively 
with the Earth-based science team, rover 
teleoperator, and the rover on the lunar surface? 

2. How will science data be made available to the 
science team? 

3. What is the affect of a particular work system 
design on the power consumption of the rover 
during a science traverse into a permanent dark 
crater? 

To answer these questions we developed a model of 
the activities of the teams, based on the description of a 
planned mission traverse. In the next sections we 
describe the design of this work system through the 
design of the agent model, the object model, their 
activity models, and the geographical model 

6.1. Agent Model Design 

Figure 4 shows the group membership hierarchy on 
which the design of the work system is based The 
agents in the model are the Earth-based human teams 
and the Victoria rover, as shown in Figure 3. The teams 
are represented as single agents, because at this momenr 
it is not possible to prescribe the composition and 
practices of each team in more detail. For example, the 
“plan a command sequence*’ activity of the SOT 
represents the work of the whole team, while the 
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Figure 4. Victoria Agent Model 
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individual activities of each team member remain 
unspecified. The Victoria rover is modeled as an agent 
because it has activities, including primitive actions that 
change the world, movements, and communications. 

Table l shows a possible distribution of the functions 
over the Victoria teams [12]. Details of how different 
teams collaborate to perform these functions constitute 
the work practice, as specified in the situation-action 
rules (Brahms workframes ) of the different agents. 

An example workffame for the SOT team for creating 
a command sequence for finding water ice is 
(paraphrased): When I believe that there is a possibility 
we can find water ice at the current location of the 
rover, then start the activity of finding water ice. 
Genetically, a workffame is of the form: When (I believe 
Do {activity A, conclude a new belief and/or 

fact } * 

6.2. Object Model Design 

The object model consists of the classes and 
instances of physical artifacts, as well the statically and 


dynamically created data objects during the simulation. 
The Victoria object model (Figure 5) includes classes 
for the science instruments on the rover and other 
objects contained in the rover, such as the carousel and 
the battery. Furthermore, the model includes the data 
communicator class, which includes the objects for S- 
band and UHF communication. The model also includes 
the software systems that receive and convert the 
mission data. A Brahms object represents the data 
visualization systems that present data to the Victoria 
team. The Data and CoreSample classes allow 
dynamically creating objects representing specific data 
and lunar core samples during the simulation 

6.3. Geography Model Design 

The geography model represents locations on Earth 
and the Moon (Figure 6). The areas of interest on Earth 
are Building244, where the Victoria teams and systems 
are located, and UsnSatelliteLocation, where the 













Ent ray 
Consumer 



My Bat* 

Croup 



i 






Contained 

Object 

■ 


■ 


Sci*nc* 

lnttnjm*nt 





■ 


|H 


r 

s s 


OjUFrsm 

Instrument 

f Rover 

i 

Shadow E dqa 

ClfOUStl 

V J 

1 Battery j 

A 

\ta CfMMSnl/ 


r Neutron ' 
Spectro- 
y meter 


C 


Sband 

Communica- 
tor 


3 ATM 


c 


L 


5 


-L 


Uhf 

Communica- 

tor 

1 


Softwvi 

Syatem 


3- Sand 
MGA 


C 


Cara 

Sample 


£ 


UnJv*nal 



r~ Data 

i C Ttl O 


I 


Spac* 



Convert loo 

1 Operation 

■ 

1 


NetworfcOtott 



V J 

1 L Sy«*m J 



Victoria 

OrbJtter 


Figure 5. Victoria Object Model 



UsnDishl satellire dish is located. Locations for the 
simulated scenario are represented on the Moon 

ShadowEdgeOtfCraterSNl represents the location the 
rover at the start of the simulation (the shadow edge in 
crater SN1). ShadowAreal InCraterSNl represents the 
area in the permanent shadowed SN1 crater where the 
rover will perform a drilling activity. The LandingSite 
area is represented only for completeness. 


7, Victoria Simulation Scenario 

The case study selects one of the key surface 
activities, searching for water in permanently shadowed 
craters: 

The rover has arrived at the shadow edge of crater 
site number I The batten has been fully charged 
Based on the data analysts bv the Earth-based teams, ot 





















Figure 7. Victoria Rover scenario activities 



the Clementine data available for the shadow edge area 
of crater site number l, the science team now decides 
where to go into this crater and search for water ice. 
While the rover is traversing into the crater, it is taking 
hydrogen measurements with the Neutron Spectrometer, 
When the rover arrives at the assigned location within 
this crater and it finds hydrogen there, the science team 
decides it should start drilling l Ocm into the surface 
using the SATXf, and collect a l.Occ lunar sample. 
When the rover receives this command , it starts the 
drilling activity and finally deposits the sample into the 
instrument carousel 

The rover uses two instruments in this scenario: the 
Neutron Spectrometer (to detect hydrogen — most likely 
caused by water ice — within the first half meter of the 
lunar surface below the rover) and the lunar surface drill 
(Sample Acquisition and Transfer Mechanism — 
SATVI). 

The backbone of the simulation model consists of 
three primary activities: Data uplink. Rover operations, 
and Uplink. These arc described in the next section. 

8. Simulation Results 

The simulation provides visibility into the behavior 
of the work system over time, that is, activities, 


communication, and movement of each agent and object 
After the model is developed and compiled, the Brahms 
simulation engine executes the model. A relational 
database is created, including every simulation event. An 
end-user display tool called the AgentViewer uses this 
database to display all groups, classes, agents, objects, 
and areas in a selectable tree view The end-user can 
select the agents and objects he she wants to investigate. 
The AgentViewer displays an activity time line of the 
agents and objects selected, optionally showing agent 
and object communications. Using this view the end- 
user can investigate what happened during the 
simulation. In the next three secrions we explain the key 
behaviors during the simulation. 

8.1. Data Uplink Activities 

The scenario starts with the Data Analysis and 
Interpretation Team (DAlT) retrieving the Clementine 
data image of the shadow edge area, where the rover is 
located at the start of the scenario. They review this 
image using their visualization system, represented in 
the Brahms model as a VisualizationSystem object. 
According to the work practice, they do this without 
anyone requesting that they look at the data. 
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Figure 8, Simulation of downlink and second 
uplink command activities 


This means that the DAIT needs to be know; I ) the 
location and situation of the rover at all times, 2) 
whether data is available and needs to be retrieved, and 
3) where and how they can retrieve data. 

Once the DAIT has retrieved the images, it 
communicates this to the Science Operations Team 
(SOT), and they collaboratively analyze these images 
(the AnalyzeRovorfmagcs activity). When done, the 
SOT plans the first rover command sequence. According 
to the scenario being simulated, the SOT decides that the 
rover needs to drive lor a specified amount of time ( 15 


min) into the crater to a specific location 
(ShadowArcal InCraterSN 1 ), and while driving it should 
be using its neutron detector instrument to detect 
hydrogen in the lunar surface This decision is 
communicated to the Vehicle and Spacecraft Operations 
Team (VSOT). as well as to the DAIT After this 
communication, the SOT waits for the rover's downlink 
data. 

8.2. Rover Activity 

The Victoria rover i>» modeled as an agent, whereas 


$ 






the neutron spectrometer and SATM instruments are 
modeled as separate science instrument objects 
eon rained in the rover agent, In the scenario model, the 
Neutron Speetromotcr object is active and creates a 
I IydrogcnData_ l object containing the hydrogen data 
rhat is ->ent to Earth while the VictoriaRover is Traversing 
to a permanently shadowed area within the crater SN1 
The rover then waits tor the next command sequence 
from Earth. During this time the teams on Earth are 
analyzing the hydrogen data and deciding what to do 
next, fn the Uplink activity, the rover is given the 
command to search for water ice in the permanent dark 
area This triggers a traverse, during which the SATM 
instrument will start the drilling activity. 

To collect a sample the SATM has to l) lower its 
augur to the surface, 2) drill to the depth given as part of 
the command by the SOT (in this scenario the command 
says to take a l.Occ sample at 10cm depth), 3) open the 
sample cavity door, 4) continue to drill to collect the 
sample, 5) close the sample door when done, 6) retract 
the drill from the surface, and 7) deposit the collected 
sample on the instrument carousel, (see “Drill 10cm into 
surface and take lec sample” in Figure 7). 

In the Brahms model, the Augur object creates the 
LunarSample_I object as part of its activity to capture 
the lunar sample, after opening the sample door and 
continuing the drilling to collect the l.Occ sample. The 
activity times for drilling into the surface are 
dynamically derived during the simulation. 

8.3. Downlink Activity 

When the rover detects hydrogen in 

ShadowArea 1 TnCraterSNl the downlink process starts 
(represented by the Brahms AgentViewer in Figure 8). 
The VictoriaRover agent contains the S-BandMGA 
object, which represents the S-Band transmitter on the 
rover. The VictoriaRover creates a data object with a) 
the current rover location information and b) the 
hydrogen data. This data object is then communicated to 
Earth, via the UsnDtshl object. The UsnDishl object 
communicates this data to the DataConversionSystem, 
located at NASA Ames. 

As can be seen in Figure 8 (see “Downlink process”), 
the DataConversionSystem performs two conversion 
activities, one for the hydrogen data and one for the 
location data from the rover The work system design 
requires that the data conversion system interact with the 
visualization system without human intervention. 

When the VisualizationSystem receives the newly 
converted data, the system alerts the DAIT. A member 
of the DAIT monitors the VisualizationSystem while in 
the activity WatchForDownlink (see “Detect, retrieve, 
interpret and communicate data” in Figure 8). When the 
DAIT agent detects that there is newly available neutron 


detector and location data, it retrieves the data from the 
VisualizationSystem object {the activities 
RetrieveNeutronData, InterpretNeutronData, and 
FindRoverLocacionData) 

Next, the DAIT communicates their findings to the 
SOT In the example scenario, the data suggest rhat the 
rover has found hydrogen in Shadow Area MnCrarerSn I 
Given this finding, the SOT quickly determines the next 
command sequence for the rover and communicates this 
decision to the VSOT (see “Next Rover Command 
Decision” in Figure 8). 

The communication informs the VSOT to transmit 
the command sequence to the VictoriaRover (see 
“Create command sequence” in Figure 8) The command 
sequence tells the VictoriaRover to starr the 
SearchForWaterfcelnPermanentDarkArea activity. It 
also tells the VictoriaRover that its sub-activity is to 
perform the Drill ingActivity. Parameters indicate how 
deep to drill and how big a sample to collect at that 
depth. Figure 8 shows part of this second uplink process. 

The duration of the downlink and second uplink 
processes determine the duration of the second 
DoNothing activity of the VictoriaRover, simulating the 
time the rover is waiting for the Victoria science team to 
decide the next command sequence (see “Waiting for 
Command from Science Team” in Figure 3). 

8.4. Modeling Energy Consumption of Rover 

To calculate the total energy used by the rover, we 
need to represent in the model the energy needed for 
each subsystem during a rover activiry [see equation 
(1)). The total power consumption of the rover during 
the scenario can then be calculated (equation (2)). 


(D 


(2) 


The energy consumption for every rover activity 
during the simulation of the scenario is shown in Figure 
9. In particular, the energy the rover uses during the 
Waiting activity (see “waiting for command from 
science team” in Figure 8) is defined by the energy' 
needed for Thermal Protection during driving - 
Command and Data Handling during driving While the 
rover is standing still and “doing nothing," it consumes 
power for its thermal protection and its commanding and 
data handling for its subsystems, such as us processor 
board. 

Besides the power left to use after the scenario, 
another interesting variable is the energy usage rare by 
the rover (equation < 3 > j 
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This equation shows that given the energy used in the 
scenario -drive 900m into the crater, and rake one I Occ 
sample at I Ocm depth — with the current work system 
design, the robot has used almost a third of its power: 


Energy Rate (drilling in permanent dark crater) - 0 30 



Figure 9. Rover energy used in high-level activities from 
simulation history database 
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This variable represents the rover power 
consumption, a measure of the effectiveness of the work 
system design, which can be used to compare different 
work configurations for the modeled scenario. 

9. Conclusions ^ 

In this paper we described how Brahms was used to 
design the mission operations work system for the [9] 

Victoria mission. 

The Brahms simulation showed the impact of the 
work practice of Earth-based teams on activities and [10] 

energy consumption of the rover. The simulation allows 
mission designers to compare different work system 
designs before critical mission decisions have been 
implemented. 

We have shown an instance of a collaborative work 
system design methodology incorporating simulation, [II] 

The Brahms simulation framework provided guidance to 
mission and robot designers, replacing a spreadsheet 
approach by a more transparent and flexible multiagent 
representation. 
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